Add capabilities for reusable blocks #4725

noisysocks · 2018-01-29T07:25:23Z

🔒 What this does

Adds capabilities for the reusable block custom post type and maps them to the default WordPress roles. The capabilities are mapped as per #3936 (comment):

Contributors can see and use existing blocks. The can edit/delete blocks for which they're the post_author. There's no draft reusable blocks, so no equivalent for them to be able to create blocks.

Authors can create blocks, and edit/delete blocks for which they're the post_author.

Editors and above can create/edit/delete all blocks. They can change the post_author for all blocks.

Here's a table to help illustrate:

	Admins/Editors	Authors	Contributors	Subscribers/Visitors
Create	Yes	Yes	No	No
Read	Yes	Yes	Yes	No
Update/Delete	Yes	Own	Own	No

✅ How I tested this (and how you could too)

I've added unit tests which run through the cases described by the table above.

You could also test this manually. First, I used WP-CLI to make sure I was working with a clean slate:

$ wp site empty
$ wp role reset --all

Then I created a bunch of users with different roles:

$ wp user create editor editor@local.test --role=editor --user_pass=password
$ wp user create author1 author1@local.test --role=author --user_pass=password
$ wp user create author2 author2@local.test --role=author --user_pass=password
$ wp user create contributor contributor@local.test --role=contributor --user_pass=password
$ wp user create subscriber subscriber@local.test --role=subscriber --user_pass=password

Then I tested various reusable block API operations while authenticated as different users. Here I'm using HTTPie, but any API client would work. Make sure your WordPress has the basic-auth plugin installed.

$ http -a editor:password POST local.wordpress.test/wp-json/wp/v2/blocks title='Editor block' content=Test

Adds capabilities for creating, reading, updating and deleting reusable blocks. The capabilities are mapped like so: | | Editors^ | Authors | Contributors | Subscribers* | | ------ | -------- | ------- | ------------ | ------------ | | Create | Yes | Yes | No | No | | Read | Yes | Yes | Yes | No | | Update | Yes | Own | Own | No | | Delete | Yes | Own | Own | No | ^ Includes administrators. * Includes visitors that are not logged in.

noisysocks · 2018-01-30T04:33:51Z

lib/register.php

+	$contributor->add_cap( 'read_blocks' );
+	$contributor->add_cap( 'delete_blocks' );
+	$contributor->add_cap( 'delete_published_blocks' );
+	$contributor->add_cap( 'edit_published_blocks' );


Is there a more suitable hook to do this work in? I read through the relevant WordPress docs but couldn't figure out a better place to do it.

init is fine, this will end up in schema.php when it lands in Core.

That said, let's wrap it in a check for if the capabilities have already been added: each add_cap() call causes a database write, which we don't really want to be doing every page load. 🙂

Fixed in a206f51.

noisysocks · 2018-02-26T22:55:03Z

@pento @brandonpayton—I think this works (well, the test cases I wrote definitely pass...) but this capabilities stuff is pretty hairy so I'd love a second pair of 👀s on this.

pento

Functionality looks good, just needs the performance tweak I mentioned.

pento · 2018-03-06T07:21:21Z

lib/register.php

+	$contributor->add_cap( 'read_blocks' );
+	$contributor->add_cap( 'delete_blocks' );
+	$contributor->add_cap( 'delete_published_blocks' );
+	$contributor->add_cap( 'edit_published_blocks' );


init is fine, this will end up in schema.php when it lands in Core.

That said, let's wrap it in a check for if the capabilities have already been added: each add_cap() call causes a database write, which we don't really want to be doing every page load. 🙂

carlhancock · 2018-03-06T15:13:45Z

Contributors can see and use existing blocks. The can edit/delete blocks for which they're the post_author. There's no draft reusable blocks, so no equivalent for them to be able to create blocks.

@noisysocks @pento The description and table says that Contributors can edit/delete blocks for which they're the post_author. But at the same time it says they can only see and use existing blocks and cannot create them. If they cannot create them, why can they edit/delete them?

Here is what the permissions table is above:

	Admins/Editors	Authors	Contributors	Subscribers/Visitors
Create	Yes	Yes	No	No
Read	Yes	Yes	Yes	No
Update/Delete	Yes	Own	Own	No

Shouldn't it actually be:

	Admins/Editors	Authors	Contributors	Subscribers/Visitors
Create	Yes	Yes	No	No
Read	Yes	Yes	Yes	No
Update/Delete	Yes	Own	No	No

Example:

User has Author role and thus the capabilities to create blocks.
User creates a block.
For whatever reason User is bumped down from Author to Contributor.
User can no longer create blocks.
But User can edit and delete blocks he created when he originally had the Author role.

Shouldn't the Contributor have strictly Read access to use blocks and no update/delete at all if they have no create capability? Even if the block was originally created by them while they had higher role access?

noisysocks · 2018-03-07T00:31:06Z

Good catch, @carlhancock. The weirdness comes from the fact that there is an implicit publish action contained within the create action. This is because reusable blocks are immediately published when they are created. Contributors cannot publish posts or pages, and so I made it so that they cannot create reusable blocks.

It seems totally reasonable to implement your suggestion and make it so that contributors cannot update or delete blocks.

Avoid calling $role->add_cap() when the role already has the given capability. This avoids an unnecessary database write.

Make reusable block permissions more consistent by preventing contributors from *editing* blocks - not just creating.

noisysocks · 2018-03-08T18:35:03Z

I've updated this PR. Let me know what you think! 💃

pento

🕺🏻💯👍🏻

westonruter · 2018-03-09T20:15:08Z

lib/class-wp-rest-blocks-controller.php

+	public function check_read_permission( $post ) {
+		// Ensure that the user is logged in and has the read_blocks capability.
+		$post_type = get_post_type_object( $post->post_type );
+		if ( ! current_user_can( $post_type->cap->read_post, $post->ID ) ) {


Minor point, but you should be able to provide the edit_post meta capability here instead rather than looking up the primitive directly, since map_meta_cap() will be doing it for you later anyway. So then this line can be simply:

if ( ! current_user_can( 'read_post', $post->ID ) ) {

You're right, this could be simply ! current_user_can( 'read_block', $post->ID ). But I like that how this currently is means that if the name of the capability in lib/register.php is changed, the controller code doesn't need to be updated.

If you use read_post (not read_block) then map_meta_cap() should automatically map it over to read_block (or whatever the registered post type cap gets changed to).

EarthmanWeb · 2021-05-13T20:21:10Z

Hello, @noisysocks I'm a bit confused - It looks like this PR was merged, but I can't find these 'block' caps in WordPress core - how do I use these capabilities please?

noisysocks added the [Status] In Progress Tracking issues with work in progress label Jan 29, 2018

noisysocks force-pushed the add/reusable-block-security branch from a82d73d to f4a8d92 Compare January 30, 2018 04:14

noisysocks added [Feature] Synced Patterns Related to synced patterns (formerly reusable blocks) [Type] Enhancement A suggestion for improvement. and removed [Status] In Progress Tracking issues with work in progress labels Jan 30, 2018

noisysocks commented Jan 30, 2018

View reviewed changes

noisysocks requested review from pento and aduth January 30, 2018 04:34

pento requested changes Mar 6, 2018

View reviewed changes

pento mentioned this pull request Mar 6, 2018

Refer to reusable blocks as 'Shared Blocks' #5322

Merged

noisysocks added 2 commits March 8, 2018 12:37

Only call add_cap() when necessary

a206f51

Avoid calling $role->add_cap() when the role already has the given capability. This avoids an unnecessary database write.

Prevent contributors from editing reusable blocks

6faa40a

Make reusable block permissions more consistent by preventing contributors from *editing* blocks - not just creating.

pento approved these changes Mar 9, 2018

View reviewed changes

noisysocks merged commit fbd99d0 into master Mar 9, 2018

noisysocks deleted the add/reusable-block-security branch March 9, 2018 17:11

carlhancock mentioned this pull request Mar 9, 2018

It's not obvious a reusable block is a reusable block #5225

Closed

westonruter reviewed Mar 9, 2018

View reviewed changes

noisysocks mentioned this pull request Jun 25, 2018

WIP: Blocks: Reimplement shared block as embedded editor #7453

Closed

noisysocks mentioned this pull request Oct 19, 2018

REST API: Use posts endpoint for reusable blocks #10751

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add capabilities for reusable blocks #4725

Add capabilities for reusable blocks #4725

noisysocks commented Jan 29, 2018 •

edited

Loading

noisysocks Jan 30, 2018

pento Mar 6, 2018

noisysocks Mar 8, 2018

noisysocks commented Feb 26, 2018

pento left a comment

pento Mar 6, 2018

carlhancock commented Mar 6, 2018 •

edited

Loading

noisysocks commented Mar 7, 2018

noisysocks commented Mar 8, 2018

pento left a comment

westonruter Mar 9, 2018

noisysocks Mar 9, 2018

westonruter Mar 9, 2018

EarthmanWeb commented May 13, 2021

Add capabilities for reusable blocks #4725

Add capabilities for reusable blocks #4725

Conversation

noisysocks commented Jan 29, 2018 • edited Loading

🔒 What this does

✅ How I tested this (and how you could too)

noisysocks Jan 30, 2018

Choose a reason for hiding this comment

pento Mar 6, 2018

Choose a reason for hiding this comment

noisysocks Mar 8, 2018

Choose a reason for hiding this comment

noisysocks commented Feb 26, 2018

pento left a comment

Choose a reason for hiding this comment

pento Mar 6, 2018

Choose a reason for hiding this comment

carlhancock commented Mar 6, 2018 • edited Loading

noisysocks commented Mar 7, 2018

noisysocks commented Mar 8, 2018

pento left a comment

Choose a reason for hiding this comment

westonruter Mar 9, 2018

Choose a reason for hiding this comment

noisysocks Mar 9, 2018

Choose a reason for hiding this comment

westonruter Mar 9, 2018

Choose a reason for hiding this comment

EarthmanWeb commented May 13, 2021

noisysocks commented Jan 29, 2018 •

edited

Loading

carlhancock commented Mar 6, 2018 •

edited

Loading